The second commit message is wrong I believe.

Restoring watchers is a nice-to-have functionality anf perf improvements are always welcome I guess, but I have some concerns:

1. Is the perf improvement noticable ? (OOC, have you done any meassurements ?)
2. We take a not-so-simple process/concept and add quite a bit of extra magic to it. If we decide to land this, I'd suggest adding some inline comments explaining the magic to future maintainers.
3. Although $$watchers is a private property and shouldn't be messed around by users, I wouldn't be surprized if there are cases where people are trying to manipulate it in a way that breaks with this change.

I'm not sayng these are reasons not to move this forward, but rather things to take into consideration.

I would be also interested in the motivation behind these changes ? Is there some specific usecase we are trying to support ? Did the need came up in a "real-world" app.

tl;dr

WRT the perf improvement:

• Nice-to-have if not negligible.
• I would prefer a less "magical" implementation (if possible - OK if it's not).

WRT restoring deregistered watchers:

• Nice addition.
• I would prefer a less "magical" implementation (if possible without impacting performance).

WRT the perf improvement:

• Nice-to-have if not negligible.

Even when performance improvement is tiny, but this change is needed for the second commit to be efficient.

• I would prefer a less "magical" implementation (if possible - OK if it's not).

I do not find anything magical in it. It can be simplified to

• Add a consecutive id to each watcher
• When removing a watcher use the id to do a binary search

WRT restoring deregistered watchers:

• Nice addition.

Thanks!

• I would prefer a less "magical" implementation (if possible without impacting performance).

I would not call the implementation magical, it adds some small complexity with all the extends but the crux of the matter is that when restoring a watcher, we do the same binary search to know where to restore it to.

The need for this came from a real-world need to lower the number of watchers and restore them once some specific even happen (and not having to keep all the scopes/expressions/listeners nor having to mess with $$watchers). Eg. Having a big object that displaying the entire content triggers 100s of watchers, and it is known when the object changes (the object is read-only and there is complete control on when it is reloaded).

I don't know if it's just me, but binarySearch seems a bit "magical" to me.
By "magical", I mean that I can't tell with a quick look what it does or what is returned and how to use it to restore the item into the array. I have to take a careful look at the implementation.

I like the idea to have a unique id every time a new watcher is created, in real life we sometimes need this (and so had implemented it our angular.js copy) to simplify debugging.

We are planning to go with a more explicit version of this: #10658